MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 048

Internet Message Format | 1997-05-06 | 40KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-048
Date: Thu, 28 Jul 1994 15:48:03 +0200 (MET DST)

C.S.M.P. Digest             Thu, 28 Jul 94       Volume 3 : Issue 48

Today's Topics:

        Color in System 7 popups?
        Controlling Apple MultiSync Monitors
        Drag Mgr problem w- flavorTypePromiseHFS
        GWorlds and other questions - Help
        PBControl() "hangs" the Macintosh
        Patching the GetResource() toolbox routine



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Summerall  Thomas G)
Subject: Color in System 7 popups?
Date: Tue, 5 Jul 1994 23:13:04 GMT
Organization: University of Colorado, Boulder

This is probably a common question, so I apologize in advance.

Can the standard system 7 popup cdef use colored menu items?  If so, how?  It
doesn't seem to recognize mctb resources associated with the menu I'm
adding.  What am I missing here?  If it isn't a feature of system 7, is
there a public domain library that can accomplish this?

Thanks,

Tom Summerall


+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Wed, 13 Jul 1994 01:59:45 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Summerall  Thomas G <[e-mail]> wrote:
>This is probably a common question, so I apologize in advance.
>
>Can the standard system 7 popup cdef use colored menu items?  If so, how?  It
>doesn't seem to recognize mctb resources associated with the menu I'm
>adding.  What am I missing here?  If it isn't a feature of system 7, is
>there a public domain library that can accomplish this?

Soon there will be a free CDEF that supports color. My popup CDEF
already does most of what you might wan, but its current version
(1.0b3) doesn't work in color grafports. I'm adding color support
right now, and it should be ready within a week or two. There are
still some bugs (visual appearance things, not crashing) that may
require another release or two before I finally discover the magical
solution. The system 7 CDEF seemed to crash when I added a mctb
resource and tried to display the menu's title. I'm also thinking of
adding coloration using an auxillary control color resource, with part
codes for the text, outline, down arrow, etc. of the control.

While on this topic, the width of my CDEF is perfect when run on a
macplus. That is, when the menu is displayed, its width is enlarged to
cover the down arrow and the margins around the menu. But on a Quadra,
the width isn't enlarged, it just is set to the actual width of the
menu. Just before calling PopupMenuSelect I set the menuWidth field of
the menu handle to the desired width, but on the color machine the
width I specify is just being ignored. Does anyone know of some
magical workaround to this problem?
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Wed, 13 Jul 1994 21:47:09 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>, [e-mail] (Ari I
Halberstadt) wrote:

> While on this topic, the width of my CDEF is perfect when run on a
> macplus. That is, when the menu is displayed, its width is enlarged to
> cover the down arrow and the margins around the menu. But on a Quadra,
> the width isn't enlarged, it just is set to the actual width of the
> menu. Just before calling PopupMenuSelect I set the menuWidth field of
> the menu handle to the desired width, but on the color machine the
> width I specify is just being ignored. Does anyone know of some
> magical workaround to this problem?
>
   The problem/situation is that PopupMenuSelect() will call CalcMenuWidth
on the menu before the menu gets drawn and so the MDEF will recalc the
size w/o the arrow :(.   The standard solution to this is to create a
"stub" MDEF which knows to resize the width on a calc message.  If you
need a code sample, let me know.


Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

---------------------------

>From [e-mail] (Troy Gaul)
Subject: Controlling Apple MultiSync Monitors
Date: Fri, 08 Jul 1994 22:57:23 -0700
Organization: Infinity Systems

Is there an API that can be used to determine when the resolution of a
MultiSync monitor changes?  Obviously, one could walk the GDevices when
returning from being switched into the foreground, or checked during idle
time, but is there any other way to find out immediately?

On a related note, is there any way to force a change of resolution via a
call (or a driver Control call)?  I'm considering an extension that would
facilitate changing monitor resolutions, but I haven't been able to find
the developer notes for MultiSync monitors.

Thanks,
_troy
//////// //////___Troy [e-mail]___//
  //    //      Infinity Systems                                  //
 //    //  //  Redmond, Washington                               //
//    //////____________________________________________________//

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 13 Jul 1994 18:40:06 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Troy Gaul,
[e-mail] writes:
>Is there an API that can be used to determine when the resolution of a
>MultiSync monitor changes?  Obviously, one could walk the GDevices when
>returning from being switched into the foreground, or checked during idle
>time, but is there any other way to find out immediately?

Yes, but somehow nobody wrote any tech notes yet.
The API is defined in <Displays.h>, but is cryptic at best.

The Display Manager allows an application to install an AppleEvent
handler to detect when a display has been changed (e.g., a new display
has come online because you've docked a Duo, or you change the resolution
of a multisynch monitor via the monitors control panel).

BTW: Extensions can supply a callback function instead of relying on an
AppleEvent.

In order to receive this AppleEvent, you must set the displayManagerAware
bit in your size resource, and install an AppleEvent Handler for
kCoreEventClass,kSystemConfigNotice (or something like that).

NOTE: If you choose to become "display manager aware", you must also be
prepared to deal with the change in displays and keep your windows
onscreen.

This is just screaming for a tech note, some sample code, and a develop
or MacTech magazine article.

-Dave Falkenburg
-Apple Computer, Inc.

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 13 Jul 1994 18:43:25 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Troy Gaul,
[e-mail] writes:
>On a related note, is there any way to force a change of resolution via a
>call (or a driver Control call)?  I'm considering an extension that would
>facilitate changing monitor resolutions, but I haven't been able to find
>the developer notes for MultiSync monitors.

Oops.  Forgot to mention that all you really need to do this is a special
video adapter cable. I have an NEC 6FG & their "PowerMac" video cable
adpater which converts the Mac's video cable into that industry standard
SVGA type connector.

Under System 7.1.2 on a PowerMac, or System 7.5 on most other recent
machines with built in video, all you need to do is go to the Monitors
control panel to swich resolutions.

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

>From [e-mail] (Ron Schneider)
Subject: Drag Mgr problem w- flavorTypePromiseHFS
Date: Tue, 12 Jul 1994 22:36:36 -0600
Organization: Just a guy...


I'm playing with the drag manager, and have incorporated it into my app.
Everything works fine, all my handlers are called, I'm dragging text
between apps, sounds, creating clipping flies, etc.  Most cool.

But I can't get flavorTypePromiseHFS to work.  As I'm dragging around, the
Finder correctly hilites applications that accept the file type I specified
in the PromiseHFSFlavor struct, and my DragSendDataProc is called back at
the correct time to return the FSSpec of the created file.  But nothing
ever happens!  The TrackDrag routine returns noErr.  I have AppleEvents
turned on, DragPeek returns the expected results, System 7.1 w/ the
DragManager, Clipping Extension, etc all installed and working.  I am
reduced to random changes hoping to stumble onto the solution.  Here are
some questions I have come up with.

1.  Are there any examples in the universe that show the 'phfs' flavor in
use?  Or anywhere in the finder that uses it so I could use DragPeek to
look at what is happening?

2.  The doc says (I love online docs!) 'This structure (PromiseHFSFlavor)
allows you to create the file in your DragSendDataProc, and provide the
FSSpec for the new file at that time.'  What does this really mean?  In the
DragSendDataProc do I specify a completed HFSFlavor, or a completed FSSpec,
or maybe an alias like all the AppleEvent stuff?  I have tried all, same
non-results.

3. I have noticed the Finder trims its FSSpecs in the 'hfs ' flavors to the
minimum length, whereas it is easier for me to pass sizeof( HFSFlavor ) or
sizeof( FSSpec ), since the filename length is in the structure anyway.
Does it matter?  (I have tried both).

Thanks for any help, suggestions, sympathy, or pointers that you can offer!

--

ron schneider
[e-mail], [e-mail]
.sig under construction

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Wed, 13 Jul 1994 21:53:32 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>, [e-mail] (Ron Schneider) wrote:

> 1.  Are there any examples in the universe that show the 'phfs' flavor in
> use?  Or anywhere in the finder that uses it so I could use DragPeek to
> look at what is happening?
>
   I believe that the HFS sample app in the Mac Drag & Drop folder on the
Mozart beta CD (and therefore the WWDC CD) shows what you need to know
about using promise HFS flavors.


   Here is some "sample" code that should show what how to deal with
promiseHFS flavors in your sendProc.  This code will definitely not
compile as is (it's missing var & function declarations but shows the
important stuff!


Leonard
- ----------
pascal OSErr SampleSendDataProc(FlavorType theType, void *refCon,
ItemReference theItem, DragReference theDrag)
{
   OSErr       result = noErr;
   AEDesc         dropLoc, specDesc;
   FSSpec         myFSSpec;
   long        dataSize;
   short       tempVRef;
   long        tempDirID;

   if (theType == flavorTypePromiseSample) {
      if (!GetDropLocation(theDrag, &dropLoc)) {

         if(!GetDropLocationDirectory(&dropLoc, &defdir, &defvol)) {

            dataSize = sizeof(sampleFlavorRec);
            if (result = GetFlavorData(theDrag, theItem, flavorTypeSample,
&mySFRec, &dataSize, 0L))
               goto out;

            result = FindFolder(defvol, kTrashFolderType,
kDontCreateFolder, &tempVRef, &tempDirID);

            // Check if the destination is the trash - if so delete
            if ((tempVRef == defvol) && (tempDirID == defdir)) {
               if(firstPromise)
                  DeleteIt();
            } else {
               // you’ve been grabbed - do something with the it!!!
               if(!abort) {
                  myFSSpec.vRefNum = defvol;
                  myFSSpec.parID = defdir;
                  NameCopy(string,myFSSpec.name);

                  result =
SetDragItemFlavorData(theDrag,theItem,flavorTypePromiseSample,
                                 &myFSSpec,sizeof(FSSpec),0);
               }

            }
            firstPromise = FALSE;

         }
      }

   } else {
      return(cantGetFlavorErr);
   }

out:

   return(result ? cantGetFlavorErr : noErr);
}
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

---------------------------

>From [e-mail] (Carl B. Constantine)
Subject: GWorlds and other questions - Help
Date: Wed, 13 Jul 1994 07:59:52 -0700
Organization: Ministry of Environment, Lands & Parks

It seems, no matter how much material I read on GWorlds & CopyBits, et.
al, it doesn't answer some of my main questions.  So I humbly turn to the
experts on the net for your guided support and help.

1)  IM IV says to set RGBForeColor to White and RGBBackColor to Black
before using CopyBits to avoid colorization.  That's great, but I've seen
many examples where people don't do this.  My question is, do you have to
do it for Color GWorlds?

2) I've seen alot about rowBytes and BaseAddr values for PixMaps/BitMaps.
How you have to set it to long word aligned for fastest copying.  If you
use NewGWorld to create your offscreen port (as opposed to OpenCPort), do
you still need to set these values or does NewGWorld do it for you?

3) Develop 17 (ftp'd from ftp.apple.com) mentions in Brigham Stevens'
article "Ten Tips for Game Developers" to use CopyBits with a mask region
instead of CopyMask or CopyDeepMask because it's faster. OK, but how do I
convert my mask (sitting in a GWorld called maskWorld) to a region.  I
haven't seen any good examples of the use of BitMapToRgn anywhere (I did
look, but got more confused. IM didn't explain how to use this at all and
neither did THINK Reference)

4) Can GetGWorld and SetGWorld be used instead of GetPort and SetPort when
using offscreen GWorlds?

5) I can't seem to find the TechNote anymore called, Out of This GWorld.
Can someone tell me where to get it (prefereablly in DocViewer Format).

Thanks for all your help.

Signed,

Dazed and Confused.

--
========================================================================
Carl B. Constantine                  B.C. Environment, Lands & Parks
End-User Support Analyst             [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Giles)
Date: 13 Jul 1994 17:11:37 GMT
Organization: Cornell University Medical College

In article <[e-mail]>,
[e-mail] (Carl B. Constantine) wrote:

> 1)  IM IV says to set RGBForeColor to White and RGBBackColor to Black
> before using CopyBits to avoid colorization.  That's great, but I've seen
> many examples where people don't do this.  My question is, do you have to
> do it for Color GWorlds?

Yes, you do need it.  (BTW, it's RGBForeColor to *black* and RGBBackColor
to *white*).  If the foreground and background colors are something else,
CopyBits will do color masking, which is a cool effect, but slows things
down a lot.

> 2) I've seen alot about rowBytes and BaseAddr values for PixMaps/BitMaps.
> How you have to set it to long word aligned for fastest copying.  If you
> use NewGWorld to create your offscreen port (as opposed to OpenCPort), do
> you still need to set these values or does NewGWorld do it for you?

NewGWorld always allocates longword-aligned chunks of memory for its
screen buffer.  As long as you are copying from a longword-aligned offset
from the baseAdr, you don't need to worry.

> 3) Develop 17 (ftp'd from ftp.apple.com) mentions in Brigham Stevens'
> article "Ten Tips for Game Developers" to use CopyBits with a mask region
> instead of CopyMask or CopyDeepMask because it's faster. OK, but how do I
> convert my mask (sitting in a GWorld called maskWorld) to a region.  I
> haven't seen any good examples of the use of BitMapToRgn anywhere (I did
> look, but got more confused. IM didn't explain how to use this at all and
> neither did THINK Reference)

I assume you're using cicn's to store your graphics?  If you are, then
look at the structure of a CIconHandle in THINK Reference; in there is a
pointer to a BitMap containing the mask.  Allocate a new RgnHandle with
NewRgn(), then call BitMapToRegion() to convert the mask BitMap into a
region.  It's pretty straightforward.  Something like this:

CIconHandle myIcon = GetCIcon(kMyIconID);
if (myIcon) {
    RgnHandle myMaskRgn = NewRgn();
    if (myMaskRgn) {
       char hState = HGetState((Handle)myIcon);
       OSErr theErr;
       HLock((Handle)myIcon);
       theErr = BitMapToRegion(myMaskRgn, &(*myIcon)->iconMask);
       HSetState((Handle)myIcon, hState);
       if (theErr == noErr) // everything worked!
    }
}

However, you need to be careful, because the mask BitMap was originally in
the source coordinates of the image, so you could just pass the same mask
to CopyMask() to copy to any destination.  When you start using a mask
region for CopyBits(), however, the region is relative to the
*destination* port, so you will need to call OffsetRgn() on the mask
region to transform it from source to destination coordinates before you
copy.

That is, if you were doing CopyMask() to two different locations, you
would just do this:

CopyMask((BitMap *)*mySrcPixMap, &myMaskBitMap, (BitMap *)*myDestPixMap,
    &srcRect, &srcRect, &destRect1);
CopyMask((BitMap *)*mySrcPixMap, &myMaskBitMap, (BitMap *)*myDestPixMap,
    &srcRect, &srcRect, &destRect2);

However, if you were doing the same thing with CopyBits(), you would need
to do a little more work:

RgnHandle myDestRgn = NewRgn();
if (myDestRgn) {
    CopyRgn(myMaskRgn, myDestRgn);
    OffsetRgn(myDestRgn, destRect1.left, destRect1.top);
    CopyBits((BitMap *)*mySrcPixMap, (BitMap *)*myDestPixMap,
        &srcRect, &destRect1, mode, myDestRgn);
    CopyRgn(myMaskRgn, myDestRgn);
    OffsetRgn(myDestRgn, destRect2.left, destRect2.top);
    CopyBits((BitMap *)*mySrcPixMap, (BitMap *)*myDestPixMap,
        &srcRect, &destRect2, mode, myDestRgn);
}

> 4) Can GetGWorld and SetGWorld be used instead of GetPort and SetPort when
> using offscreen GWorlds?

Yes; in fact, they *must* be used.  I never use SetPort() anymore;
SetGWorld() always does the job and you never have to worry about pointing
to the wrong or nonexistant GDevice.

Hope this helps!
Aaron
--
Aaron Giles ([e-mail])
Power Macintosh Developer, Cornell University Medical College
JPEGView home page: http://www.med.cornell.edu/jpegview.html
JPEGView FTP site:   ftp://ftp.med.cornell.edu/pub/aarong/jpegview/

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 13 Jul 1994 12:22:25 -0800
Organization: Integer Poet Software

In article <[e-mail]>,
[e-mail] (Aaron Giles) wrote:

> In article <[e-mail]>,
> [e-mail] (Carl B. Constantine) wrote:
>
> > 1)  IM IV says to set RGBForeColor to White and RGBBackColor to Black
> > before using CopyBits to avoid colorization.  That's great, but I've seen
> > many examples where people don't do this.  My question is, do you have to
> > do it for Color GWorlds?
>
> Yes, you do need it.  (BTW, it's RGBForeColor to *black* and RGBBackColor
> to *white*).  If the foreground and background colors are something else,
> CopyBits will do color masking, which is a cool effect, but slows things
> down a lot.

You don't need to do it every time if you think it is slowing your code
down. What you do need to do is assure yourself that the foreground and
background colors are set the way you think they should be set. Most of
the time that's fore/black and back/white. It so happens that these are
the default foreground and background colors, so that accounts for why you
see code which doesn't bother to set them.

--

 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "I am Wang of Symantec. You will be assimilated. Resistance is futile."

---------------------------

>From [e-mail]
Subject: PBControl() "hangs" the Macintosh
Date: 12 JUL 94 18:21:00 GMT
Organization: Computer Technology Institute (CTI), Patras, Greece

Hi there,

I am new in Macintosh programming and I want to write two simple programs
implementing a client and a server. I am using MacTCP and I am trying to
open a UDP connection between the client and the server.

I am using Think C 5.0 on a MacQuadra 700 and MacTCP 1.1.

I wrote the following code trying to open the MacTCP driver and a UDP stream,
but when I try to  "run" it,  the  Macintosh "hangs".

- -------------------------------------------------------------------

/* Open a UDP stream */

#include <PrintTraps.h>
#include <stdio.h>
#include <MacTCPCommonTypes.h>
#include <UDPPB.h>

main()
{

 short             DrefNum=0;
 UDPiob            myUDPblock;
 CntrlParam        myUDPCblock;
 UDPCreatePB       myUDPCreate;
 Ptr               RcvBuffer;
 OsErr             MyErr;
 char              DriverName[9]="\p.ipp";

 myUDPblock.ioCompletion = NULL;
 myUDPblock.ioNamePtr = DriverName;
 myUDPblock.ioCRefNum = 0;

 MyErr = PBOpen((ParmBlkPtr)&myUDPblock,false);

 DrefNum=myUDPblock.ioCRefNum;

 if (MyErr != noErr)
    printf("Error %d\n",MyErr);
 else
    printf("No Error\n");

 myUDPCblock.csCode=20;
 myUDPCblock.ioCRefNum=DrefNum;
 myUDPCblock.oCompletion=NULL;

 RcvBuffer=(char *)malloc(2048*sizeof(char));
 myUDPCreate.rcvBuff=RcvBuffer;
 myUDPCreate.localPort=0;
 myUDPCreate.endingPort=1500;

**>> MyErr=PBControl((ParmBlkPtr)&myUDPCblock,false);  /* At this point the Mac
                                                        "hangs" */
 if (MyErr != noErr)
    printf("PBControl returned error %d\n",MyErr);
 else
    printf("No error returned\n");


}

- ----------------------------------------------------------------------------


The point where the Macintosh "hangs" is market with **>>. When I use the
debugger, at the specified point a message appears saying  "Bus Error".

Can anybody tell me, what I am doing wrong ?

Thank you in advance.

****************************************************************
Emmanuel Tzangarakis, [e-mail],   [e-mail]
Computer Technology Institute (CTI)
Patras,
Greece.

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Tue, 12 Jul 1994 18:34:26 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] writes:
>I wrote the following code trying to open the MacTCP driver and a UDP stream,
>but when I try to  "run" it,  the  Macintosh "hangs".
>
> myUDPCblock.csCode=20;
> myUDPCblock.ioCRefNum=DrefNum;
> myUDPCblock.oCompletion=NULL;
>
> RcvBuffer=(char *)malloc(2048*sizeof(char));
> myUDPCreate.rcvBuff=RcvBuffer;
> myUDPCreate.localPort=0;
> myUDPCreate.endingPort=1500;
>
>**>> MyErr=PBControl((ParmBlkPtr)&myUDPCblock,false);  /* At this point the Mac
>                                                        "hangs" */
You don't initialize your parameter block, so your code installs garbage
as an ASR. When the mac calls that garbage ASR, it bus errors.

The following does almost what you want:

/* This is a complete, correct, example of creatign a TCP stream.
    Written and tested by David Phillip Oster, 7/12/94
 */
#include "AddressXlation.h"
#include "UDPPB.h"
#include "TCPPB.h"
#include <string.h>

static short tcpRefNum = 0;

/* UDPMTU - return UDPMaxMTUSize
 */
static OSErr UDPMTU(ip_addr hostAddr, unsigned short *dgramSize){
    UDPiopb    pb;
    OSErr    err;

    if(0 == tcpRefNum){
        return openFailed;
    }
    memset(&pb, 0, sizeof pb);
    pb.ioCRefNum = tcpRefNum;
    pb.csCode = UDPMaxMTUSize;
    pb.csParam.mtu.remoteHost = hostAddr;
    pb.csParam.mtu.userDataPtr = nil;
    if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){
        *dgramSize = pb.csParam.mtu.mtuSize;
    }
    return err;
}

/* TcpCreate - opens a TCP stream.
 */
static OSErr TcpCreate(
    Ptr rcvBuff,
    unsigned long rcvBuffLen,
    StreamPtr *streamp){

    TCPiopb    pb;
    OSErr    err;

    if(0 == tcpRefNum){
        return openFailed;
    }
    memset(&pb, 0, sizeof pb);
    pb.ioCRefNum = tcpRefNum;
    pb.csCode = TCPCreate;
    pb.csParam.create.rcvBuff = rcvBuff;
    pb.csParam.create.rcvBuffLen = rcvBuffLen;
    if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){
        *streamp = pb.tcpStream;
    }
    return err;
}

/* TcpRelease - closes a Tcp stream
 */
static OSErr TcpRelease(StreamPtr stream, Ptr *rcvBuff, long *rcvBuffLen){
    TCPiopb    pb;
    OSErr    err;

    if(0 == tcpRefNum){
        return openFailed;
    }
    memset(&pb, 0, sizeof pb);
    pb.ioCRefNum = tcpRefNum;
    pb.csCode = TCPRelease;
    pb.tcpStream = stream;
    if(noErr == (err = PBControl((ParmBlkPtr) &pb, FALSE))){
        *rcvBuff = pb.csParam.create.rcvBuff;
        *rcvBuffLen = pb.csParam.create.rcvBuffLen;
    }
    return err;
}



/* main -
    although it appears that err is unused here, actually, I
    dump it out in the debugger.

    weaver is just some host this machine can reach, so I can
    ask how big a buffer to allocate, to hand to the stream.
 */
main(){
    OSErr            err;
    ip_addr            weaver_addr;
    struct hostInfo    weaverInfo;
    unsigned short     dgramSize;
    Ptr                buf, buf2;
    long            bufLen, bufLen2;
    StreamPtr        stream;

    weaver_addr = 0;

    err = OpenDriver("\p.ipp", &tcpRefNum);    /* opens the MacTCP implementation */
    err = OpenResolver(nil);
    err = StrToAddr("weaver.", &weaverInfo, nil, nil);
    if(noErr == err){
        weaver_addr = weaverInfo.addr[0];
    }
    err = CloseResolver();
    err = UDPMTU(weaver_addr, &dgramSize);
    /* the minimum memory allocation for TCP is 4L*dgramSize + 1024L */
    bufLen = 2048L + 4L*dgramSize;
    buf = NewPtr(bufLen);
    err = MemError();
    err = TcpCreate(buf, bufLen, &stream);
    err = TcpRelease(stream, &buf2, &bufLen2);
    return 0;
}

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Thu, 14 Jul 1994 07:22:48 GMT
Organization: The Information Workshop

In article <[e-mail]> , [e-mail]
writes:

> Hi there,
>
> I am new in Macintosh programming and I want to write two simple
programs
> implementing a client and a server. I am using MacTCP and I am trying
to
> open a UDP connection between the client and the server.
>
> I am using Think C 5.0 on a MacQuadra 700 and MacTCP 1.1.
>
> I wrote the following code trying to open the MacTCP driver and a UDP
stream,
> but when I try to  "run" it,  the  Macintosh "hangs".
>

< source code not included>

>
>
> The point where the Macintosh "hangs" is market with **>>. When I use
the
> debugger, at the specified point a message appears saying  "Bus Error".
>
> Can anybody tell me, what I am doing wrong ?
>
> Thank you in advance.
>
> ****************************************************************
> Emmanuel Tzangarakis, [e-mail],   [e-mail]
> Computer Technology Institute (CTI)
> Patras,
> Greece.


Emmanuel,

Your *real* problem is that you did not first draw from working example
source code.

Fortunately, David Oster supplied you with an excellent, and "known to be
working" example.  When you look at it, and compare it to yours, you will
see that there are significant differences.

The only way to be successful in programming these days is to "stand on
the shoulders of work already done" -- because there is still quite a bit
to do after that. :)

If you tackle each programming task all over from scratch, it could take
you weeks, or even months to duplicate the effort that went into David's
code alone.  It is okay for you to stand on the shoulders of that work
and utilize it directly.  If it was not okay, David would have politely
let you know.

- ---

I would wager that the mistake you made is a common one, which is using
"parameter block" type calls without first initializing them to zero.

Your parameter block structures are allocated on the stack, but they are
not initialized, so there is random stuff in all of the parameter block's
fields.  You are setting the values of some of them, but what about the
rest?

ooops. :)

The toolbox call you are making may be looking at some of the other
parameter block field and perhaps if on of them is not nil, then it
figures it must be good a valid address, and so it uses the address in
that field, not knowing that is is actually a random value -- bus error!

In David's code, the "memset" call is used to initialize a parameter
block before it is used.  Now you will remember this from now on, I am
sure!

I made the same mistake, too, and will always remember it. :)

Keep working at it!


Mark Hanrek

---------------------------

>From Dmitry Boldyrev <[e-mail]>
Subject: Patching the GetResource() toolbox routine
Date: 8 Jul 1994 01:51:15 GMT
Organization: University of Utah

Hi folx!
I am the author of LZSS Res resource compression utility. The way LZSS Res
works now
is, it has a library function called GetCResource(rType, rID) which has
a call inside it to GetResource, then, the resource is decompressed in real
time
and returned. However, it is a not very convinient way of doing that, that is
someone who's using my package would have to change GetPicture to
(PicHandle)GetCResource() and so on.. you see, it is not a good way.
Yesterday, I spoke to the current president of TopSoft, inc. Tony Jacobs who
suggested me another idea, to patch the trap GetResource() so that
whenever someone makes a call GetResource() actually my function will be called
and the resource will be grabbed decompressed and passed.
Now, is there a way to do it?

Greatly appreciate any info.

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 8 Jul 1994 02:39:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2vibej$[e-mail]>, Dmitry Boldyrev
<[e-mail]> writes:

"...suggested me another idea, to patch the trap GetResource() so that
whenever someone makes a call GetResource() actually my function will be
called and the resource will be grabbed decompressed and passed.  Now, is
there a way to do it?"

First off, you'll have to patch more than just GetResource. There are
quite a few calls that load resources: GetResource, GetNamedResource,
Get1Resource, Get1NamedResource, LoadResource, and some others. I suspect
they all come down to a call into LoadResource, but the ROM won't get
there through a trap, so you'll probably have to patch them all.

Second, you'll have to do your thing AFTER the toolbox gets the resource,
so your patch will do the actual GetResource (or whatever), then
decompress the result and return it. The problem is that by this time the
Resource Manager has already allocated a handle for the resource and made
an entry in the resource map. If you then decompress the resource into
another (larger) block and return a handle to that block to the caller,
you have a bit of a mess to clean up. First you'll have to get rid of the
resource manager's copy, with ReleaseResource. Then you'll have to patch
the ReleaseResource, DetachResource, and perhaps some other calls that
will be expecting resource handles, just in case the calling program
decides to do a resource call with the handle you gave it. The main
problem here is that resource handles are NOT the same as other blocks;
the Resource Manager keeps a private list or map of resources in the heap.

Obviously you'll have to install your patch(es) in the System Heap at boot
time (with an INIT) so they will be global to all applications. You'll
probably then find out how many other INITs patch the Resource Manager,
with possibly frustrating results. Your code isn't the only thing that
compresses and decompresses resources, so it had better be able to
identify those it has compressed and ignore anything else.

In short, this could get messy.

Gregory Jorgensen
XCommander
Radix Consulting Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ben Martz)
Date: 12 Jul 1994 02:08:23 GMT
Organization: PawPrint Enterprises

In article <2vibej$[e-mail]>, [e-mail] (Dmitry
Boldyrev) wrote:

> I am the author of LZSS Res resource compression utility. The way LZSS Res
> ...
> ... However, it is a not very convinient way of doing that...
> ..suggested me another idea, to patch the trap GetResource() so that
> whenever someone makes a call GetResource() actually my function will be
> called and the resource will be grabbed decompressed and passed.
> Now, is there a way to do it?
>
> Greatly appreciate any info.

Ok, Dmitry, first of all, a disclaimer, if you don't have a way to
determine if the resource is compressed, ADD ONE! Source code - from the
way you wrote your article, it looks like you are using C so here's some C
code for an INIT to patch a trap and call the original one:

/* GR_Patch.c, GetResource patch -- MAY NEED SOME WORK TO WORK! */
#include <SetUpA4.h>

#define CODE_SETUP() asm {\
                movem.l    a0-a5/D0-D7, -(SP)\
                move.l        a0, a4\
            }
#define CODE_CLEANUP() asm {\
                movem.l    (SP)+, a0-a5/D0-D7\
            }

#define GrafSize        206
#define ADD_GRAFSIZE    (GrafSize - 130)
typedef struct
{
    char        filler[ADD_GRAFSIZE];
    long        randSeed;
    BitMap        screenBits;
    Cursor        arrow;
    Pattern        dkGray;
    Pattern        ltGray;
    Pattern        gray;
    Pattern        black;
    Pattern        white;
    GrafPtr        thePort;
} QD_GLOBALS;

#ifndef NULL
#define NULL ( (void *)0 )
#endif

static QD_GLOBALS our_qd;

#define GetResource_Address 0xA9A0 /* yes this is the right address! */
/* define our routine*/
pascal Handle our_GetResource(ResType rType, short rID);
static void *old_GetResource;

void main(void) {
    Handle    self_handle;
    Ptr selfPtr;

    CODE_SETUP();
    asm { move.l a0, selfPtr }
    self_handle = RecoverHandle(selfPtr);
    HLock(self_handle);
    DetachResource(self_handle);

    /* get the old routine's address for future use! */
    old_GetResource = (void *)NGetTrapAddress(GetResource_Address, ToolTrap);
    /* substitute our routine! */
    NSetTrapAddress((UniversalProcPtr)StripAddress(our_GetResource),
                    GetResource_Address, ToolTrap);

    CODE_CLEANUP();
}

pascal Handle our_GetResource(ResType rType, short rID) {
    Handle returnValue;

    CODE_SETUP();
    SetUpA4();

    /* call the old GetResource to get the resource */
    returnValue = CallPascalL(old_GetResource, rType, rID);

    /* first, check to see if the resource is compressed, if so, */
 /* decompress resource here! */

    RestoreA4();
    CODE_CLEANUP();
    return(returnValue);
}


/* end of file */

BTW: I don't think that this code is powerpc compatible unless you compile
it as 68K code


Hope that this helps!

- Ben


-CUT HERE------------------------------------------------------------------

           +---------------+        --------------------------------------
          / +-----------+ /        -- Ben Martz                        --
         / /  ()   ()  / /        -- [e-mail]     --
        / /     ^     / /        -- currently residing in Ann Arbor, --
       / /  ______   / /        --       Michigan                   --
      / /  \-----/  / /        --------------------------------------
     / +-----------+ /        -- The views and opinions expressed --
    /        _____  /        --  here are mine and no one elses! --
   / *....         /        --------------------------------------
  +---------------+        -- "Football can touch a young man  --
  / / / / / / / /         -- where nobody else can...legally" --
 +-------------+         --------------------------------------=

+++++++++++++++++++++++++++

>From [e-mail] (Dave Evans)
Date: Wed, 13 Jul 1994 09:10:21 GMT
Organization: N/A

In article <2vibej$[e-mail]>, Dmitry Boldyrev
<[e-mail]> wrote:
> The way LZSS Res works now is, it has a
> library function called GetCResource(rType, rID) which has a call inside
> it to GetResource, then, the resource is decompressed in real time
> and returned. However, it is a not very convinient way of doing that, that is
> someone who's using my package would have to change GetPicture to
> (PicHandle)GetCResource() and so on.. you see, it is not a good way.

Please Dmtiry, DON'T PATCH.  Even if more technically challenging, patching
only makes your software less stable, less compatible, and much more
difficult to maintain across system software versions.  Also, your patches
may very well break other applications;  you would need to test many
applications to verify that your software was successful.  If you stick
with a linked library, you will avoid all of this.

Now, to solve your problem, I recommend you provide a library with many
routines instead of just one routine.  Name them, for example:

DBGetResource()
DBGet1Resource()
DBGetPicture()

etc.  The DB is for your name's initials, just to designate your
routines as separate from the Mac Toolbox routines.  Then write very
small routines for each which call your GetCResource() routine
as appropriate or Macro's which redefine them to casted GetCResource()
calls.  You can then also provide a header file which optionally
defines all the developer's routines to be yours instead.  E.G.:

#if hasDmtiryLibrary
#define GetResource(...)  DBGetResource()
#endif

So they don't need to change their code and can easily use your
software...  AND no patching!!!

Dave

---------------------------

End of C.S.M.P. Digest
**********************